Motor vehicles are increasingly being equipped with many complex electrical and electronic devices and functions. In place of a mechanically and/or manually activated actuator for operating the basic functions of the vehicle, there are a variety of control devices for monitoring and influencing certain components or functions of the vehicle in a typical modern motor vehicle. To do this, it is necessary for the different control devices to exchange data with each other.
Thus there are at least one motor control device, a transmission control device and other control devices involved in the control of a drivetrain of a vehicle which, for example, improve tracking in critical driving situations by specific braking interventions or can minimize the stopping distance by way of an ABS control (ABS=anti-lock braking system). At the same time the number of additional systems such as navigation and communication systems, in the vehicle and their networking to each other increases, which poses a variety of compatibility problems.
Because of the large number of different equipment variations in a vehicle from the production plant, the configuration of the control devices and the hardware components associated with them, like actuators, sensors and other control devices, represent a significant problem in the construction and design of a motor vehicle. To solve these difficulties, it is known to tune the software of a vehicle to the vehicle-specific combinations. The programming of the control devices tuned to the specific vehicle usually occurs at the end of manufacture of the vehicle and can only be changed with a lot of time and effort since, with reprogramming, the compatibility of all components and control devices in the vehicle must be verified.
Thus a procedure is known, for example, from US 2004/0260751 A1 where, in the context of a visit to a repair shop the configuration of the vehicle's built-in hardware as well as the currently stored software can be read-out in order to ensure that, in the event of any necessary change or expansion of the software, only those software modules that have been tested and released for the configuration in question will be installed. Such a procedure is only for cases in which a refitting of the vehicle is the exception and, if necessary, will take place only a few times during the life span of a vehicle, since the hardware modifications in question usually take place in a specialty repair shop. It is a disadvantage, however, that the software changes must be performed separately thereby increasing costs.
U.S. Pat. No. 6,747,366 B2 discloses a similar procedure for a power supply system of a vehicle which includes a number of intelligent network nodes, each with an internal memory for configuration data. These are read-out by an adapter when the vehicle starts and is stored in a separate memory component. At periodic intervals, the adapter checks the matching of the configuration data of the network nodes with the data stored in its own memory component. If these data do not match a network node, for example because the network node has been replaced and has no configuration data stored in it, the adapter conveys the configuration data stored in its own memory component for this network node to the internal memory, thereby configuring the new network node without any outside intervention being necessary. New configuration data can be written into the memory component of the adapter via a service interface. During the next comparison of the data stored there with the data in the network nodes, the latter are updated by being overwritten with the former and the system is updated.
This system indeed offers advantages, if only one component must be exchanged for an equal or even a fully compatible component. On the other hand, it does not offer any advantages with regard to a fast and automatic adaptation of the software configuration which depends on a hardware configuration that is present, since in the event of a component replacement, the current software parts must be externally placed in the memory component of the adapter. In addition, a failure or removal of a node is first determined during a periodic check.
A system with an external check of the hardware and software is not practical for vehicles that must be re-equipped periodically or even frequently and routinely. Thus it is the usual practice for work vehicles to attach various components to a vehicle. For example, in the case of a road maintenance vehicle there has to be the capability, depending upon the weather, of quickly and simply changing between a snow plow, a snow blower and a brush roller, where alternatively or simultaneously grit conveyors or grit distribution systems can be used. In the summer months, the same vehicle is to alternatively be used as a mowing vehicle or as a vehicle for cleaning street markings and guard rails or is operated with other work equipment. The conversion is done locally at the highway department without any visit to a workshop. An external reprogramming of control equipment after each conversion is neither practical nor justifiable, since the conversion times are to be kept as short as possible especially with regard to clearing operations. The same is true, for example, for vehicles used in agriculture, fire departments and technical assistance services.
As an alternative to the previously described possibility of an individually tuned programming of the control devices, it is known to provide vehicle control devices with a memory element in which not only the currently needed software configuration for the current vehicle configuration is stored, but also alternative configurations. Known from WO 00/77620 A2 is a computerized network system for a vehicle in which the individual components are connected via a network and which enables a simple reconfiguration, as well as an upgrade of the vehicle. If a component is connected to the network where a special “discovery and join” protocol governs, it automatically registers with the network server and is integrated into the network whereupon other components search the network server for new functions which the newly attached components possibly make available. The components to be installed can contain a memory in which information about the executable functions and functions required by other components are stored. In this, the registration must be repeated within certain time periods. On the other hand, the system assumes that the associated component is again removed and erases the associated information.
The result is that the repeating of the registration must take place within very short time intervals and with corresponding greater stress on the entire system or the user runs the risk that after the deactivation of a component the vehicle will operate for a certain time without a current software configuration. This is not only disadvantageous, but can also result in serious malfunctions or at least an unjustified error reporting, because of the various reciprocal effects between different hardware and software components. Furthermore, it is not guaranteed that differentiation can be made between the intended removal of a component and a failure of the component.
The German patent DE 199 26 206 C2 discloses a vehicle electric configuration system for the automatic configuration of vehicular electrical systems in which the attached hardware components, which are attached at least partially to a data bus network, incorporate at least in part implemented software components to perform associated functions. Furthermore, a vehicle-related, central, actual configuration data memory for the retrievable application of a current configuration fitting the respective vehicle is envisioned.
In the case of a replacement, an upgrade or a new installation of a component the previous actual configuration can thus be retrieved in a simple manner and updated, if need be. To do this, all partial systems of the vehicle electric arrangement can be acquired with their associated component relationships by the system developer. In order to be certain that the actual configuration does, in fact, depict the current, actually available system, it is envisioned that each control device component is able to identify itself. Since the data read by the hardware components contain, in addition to internal details and the actually implemented software of the components, also data about attachable actuators and sensors, as well as possible and usable resources, like power cables, connections, bus identifiers, memory areas and CPU usage, a check of the compatibility of replacement parts can be performed with their help using the available hardware and software. In any event, required for a component replacement or a component upgrade is the use of a system user which identifies the appropriate component in the configuration.
The system is thus not able to react in a fully automatic manner to an upgrade, a conversion or another change in the configuration. To be sure, a vehicular electric configuration means is claimed in Claim 5 of this document, which envisions a reconfiguration means for a computer-supported, automatic reconfiguration of a vehicular electric arrangement upon the replacement of at least one component with at least one new component of a corresponding function or another type or the addition of at least an additional component for a new functionality or, in the event of a change, at least a component relationship. However, this involves a menu-supported program in which the determination of the actual configuration occurs only in a fully automatic manner after the manual input of data. The solution of DE 199 26 206 C2 also is not suited for the fastest possible updating of the software-related, current configuration independent of the driver/operator.
A control device for the operation of a deployment vehicle is known from WO 2004/053602 A1, in particular a fire truck and additional components either integrated into or externally operable with the deployment vehicle. It includes a configuration unit which has a communication linkage with a computer device placed in an electronic module. Software functions are stored in a memory device which can be associated with the connection contacts of the input and output interfaces of the electronic module. The configuration unit is associated with at least one input unit and a display device. However, this does not involve a fully automatic system, but only an improved access possibility for the electronic modules of the individual systems that can be programmed or configured in this manner.
Finally, a procedure is known from DE 10 2004 055 875 A1 for the application-specific configuration of software. Selected from a quantity of several application-specific software parts is a subset, which is deposited in compiled form in a control device. Variables are assigned to these selected software parts. For example, the software can consist of a control of driving dynamics consisting of three different parts to which the variables A, B and C are assigned. In a vehicle, which can selectively make a front wheel drive or an all wheel drive available, it is then possible to block a software part C for a rear wheel drive by setting a parameter so that it cannot be loaded into the control. The other two software parts A and B are conveyed to the control unit. Depending on the actual application case, in this case whether the driver activates a front wheel drive or an all wheel drive, the applicable software part A or B is compiled and is made available to the control unit.
This procedure, to be sure, facilitates the selective use of a component in various software modes, but it does not provide any indication of an integration of a replaced or added component into the system or the recognition of a configuration after the disassembly or addition of a component.
It is, however, desirable in vehicles and in particular commercial vehicles, that the configuration can be changed, especially in relation to the re-equipping or removal of hardware components during the useful life of the vehicle, without an external system having to be connected or a new configuration of the system being required by an operator.
It is thus desirable in trucks, for example, if a vehicle ordered without a retarder, a hub drive or an ASR (automatic slippage regulator) can be retrofitted quickly and at a reasonable cost, when needed. This, however, assumes the subsequent integration of the control device of the retarder, the hub drive and/or a change of the software or the parameters for operation, e.g., of the motor control system, and therefore often causes a costly new programming of other control devices or even an exchange of the central control device.
While it is basically known from DE 10 2004 055 875 A1 how to program a single software for various variations of a motor vehicle, from which the actual configuration of the parts pertaining to the vehicle is selected, a practical procedure has been missing up to now for reliably determining the actual hardware configuration such that, after the run-up of a control device of a vehicle, the actual configuration is known and the pertinent software configuration is set.
Against this background, the invention has the task of introducing a procedure for an adaptive configuration recognition that, directly after the start or run-up of a control device, recognizes which components and/or functions are actually present in or on the vehicle and which can be automatically adapted to the software configuration of the vehicle and/or the error management system.